runtime: block signal_recv on targets without signal delivery (#5619) by neomantra · Pull Request #5620 · tinygo-org/tinygo

neomantra · 2026-08-28T01:33:01Z

This was worked through with LLM. The text below is LLM-generated and I have read and reviewed all the code.

But I did finally get the BubbleTea List demo running in browser, compiled by TinyGo!

Summary

Make the stubbed os/signal.signal_recv block forever instead of returning
immediately, so signal.Notify no longer starves cooperative schedulers on
wasm and baremetal targets.

Fixes #5619

Problem

src/runtime/signalstub.go (build tags tinygo.wasm || baremetal) stubbed
signal_recv as return ^uint32(0). Upstream's os/signal.loop calls
signal_recv in a tight loop with no yield point — it relies on the
runtime blocking until a signal arrives, as the POSIX implementation in
runtime_unix.go does. With the immediate-return stub, the watcher
goroutine started by signal.Notify spins forever.

On a cooperative scheduler a spinning goroutine is always runnable, so the
scheduler never idles: on wasm, _start never returns to the host event
loop and the browser tab (or node/wazero) pins a core with all other
goroutines starved. Any program calling signal.Notify is affected —
Bubble Tea does so unconditionally, which is how this surfaced (a V8
profile of the hung program showed 99.7% of ticks in os/signal.loop).

Fix

signal_recv now calls deadlock() — the same primitive a blocking empty
select uses — parking the watcher goroutine forever. That matches the
real implementation's observable behavior on a system where no signal ever
arrives: Notify succeeds, the channel simply never receives anything, and
everything else keeps running. This is also what gc's js/wasm port does.

Verification

New behavioral test testdata/signalnotify.go (signal.Notify, then
time.Sleep, then print done), registered for all platforms. The
existing signal.go test is skipped on wasm/baremetal/windows, which is
why this had no coverage.
Red: on stock dev @ 86d58db the wasm test hangs until the Go test
timeout kills it.
Green with this change: TestBuild/WebAssembly/signalnotify.go and
TestBuild/Host/signalnotify.go both pass (the host run exercises the
real POSIX signal_recv path, guarding both implementations).
End to end: a go-booba-adapted Bubble Tea bubbles/list app compiled for
GOOS=js GOARCH=wasm previously froze the browser tab at 100% CPU right
after startup; with this change it runs interactively.
deadlock() is defined by all four scheduler implementations
(cooperative, threads, cores, none), covering the stub's whole build-tag
surface.
Not run locally: cortex-m-qemu / AVR / RISC-V builds of the new test
(this environment lacks the LLVM source checkout for compiler-rt); CI
covers those. If os/signal turns out not to fit AVR flash, the test can
be excluded for AVR the way json.go/stdlib.go are.

Context

Found while verifying the large-parameter-spilling work (#5615) in a real
browser; it is independent of that change and reproduces on stock dev.

0pcom · 2026-09-05T00:07:58Z

Independently verified this fix, from outside the CI harness: applied just the signalstub.go change to a stock 0.41.1 TINYGOROOT and ran the equivalent of testdata/signalnotify.go (signal.Notify + time.Sleep + println) under node v26 with GOOS=js GOARCH=wasm.

Stock runtime: the program never prints and the JS event loop is starved completely — a setTimeout watchdog queued before go.run never fires either, matching the "no JavaScript ever runs again" symptom in os/signal: signal.Notify permanently starves the scheduler on wasm (stubbed signal_recv returns immediately) #5619 exactly.
With this patch: prints done immediately and the event loop stays live.

The deadlock() shape also seems right rather than just expedient: it parks the os/signal.loop goroutine the same way the real implementation blocks while no signal is pending, the cooperative scheduler carries on, and since signalstub.go is also the baremetal path it fixes the same starvation there. Works against the 0.41.1 runtime sources unchanged, so it should backport trivially if a point release happens before 0.43.

Copilot

🟡 Changes recommended

The new test will fail to link on Windows without an exclusion or Windows signal stubs.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Prevents signal.Notify from starving cooperative schedulers on targets without signal delivery.

Changes:

Blocks stubbed signal reception indefinitely.
Adds and registers a scheduler-progress regression test.
Defines the expected test output.

File summaries

File	Description
`testdata/signalnotify.txt`	Defines expected output.
`testdata/signalnotify.go`	Tests progress after `signal.Notify`.
`src/runtime/signalstub.go`	Parks unsupported signal reception.
`main_test.go`	Registers the test, but does not exclude unsupported Windows hosts.

Review details

Files reviewed: 4/4 changed files
Comments generated: 1
Review effort level: Balanced

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

 		"print.go",
 		"reflect.go",
 		"signal.go",
+		"signalnotify.go",


deadprogram · 2026-09-17T09:00:51Z

I have not really looked into this PR, but it for sure needs a couple of things:

rebase against the latest dev
update it based on the AGENTS.md file guidelines

Thanks!

neomantra · 2026-09-18T21:40:56Z

I've rebased, simplified the comments, and addressed the Copilot Windows skipping suggestion.

deadprogram · 2026-09-19T13:22:10Z

Thanks @neomantra for the rebase and the updates. Almost there, just one little thing. See below, edited from an automated review:

The new Windows skip in main_test.go has no reason comment, while the other skips in runPlatTests all explain themselves. Please add a short reason, and consider folding it into the signal.go skip just above it. For example:

if options.GOOS == "windows" {
	switch name {
	case "signal.go", "signalnotify.go":
		// os/signal does not link on Windows.
		continue
	}
}
if isWebAssembly || isBaremetal {
	switch name {
	case "signal.go":
		// Signals only work on POSIX-like systems.
		continue
	}
}

The signal_recv stub returns immediately. After signal.Notify starts the signal goroutine, os/signal.loop calls the stub continuously. On cooperative schedulers, this prevents other goroutines from running. On js/wasm, it also prevents control from returning to the host. Call deadlock() to block the signal goroutine permanently. These targets cannot deliver signals. Add a regression test that calls signal.Notify and then sleeps. The test checks that the main goroutine can resume and exit. Skip this test on Windows, which has no signal implementation. Fixes tinygo-org#5619 Signed-off-by: Evan Wies <evan@neomantra.net>

neomantra · 2026-09-19T18:13:15Z

I've rebased this and addressed that comment, thanks!

deadprogram

Thanks for this @neomantra

jakebailey requested a balanced review from Copilot September 5, 2026 02:11

Copilot started reviewing on behalf of jakebailey September 5, 2026 02:12 View session

Copilot AI reviewed Sep 5, 2026

View reviewed changes

Comment thread main_test.go

"print.go",

"reflect.go",

"signal.go",

"signalnotify.go",

neomantra force-pushed the nm-signal-stub branch from 6c61020 to 6fc5dfd Compare September 18, 2026 21:32

neomantra force-pushed the nm-signal-stub branch from 6fc5dfd to 42470f6 Compare September 19, 2026 17:32

neomantra force-pushed the nm-signal-stub branch from 42470f6 to ff13b73 Compare September 19, 2026 17:43

deadprogram approved these changes Sep 19, 2026

View reviewed changes

deadprogram merged commit d4ebca0 into tinygo-org:dev Sep 19, 2026
33 checks passed

neomantra deleted the nm-signal-stub branch September 28, 2026 16:01

Navigation Menu

Uh oh!

runtime: block signal_recv on targets without signal delivery (#5619) - #5620

runtime: block signal_recv on targets without signal delivery (#5619)#5620
deadprogram merged 1 commit into
tinygo-org:devfrom
neomantra:nm-signal-stub

neomantra commented Aug 28, 2026

Uh oh!

0pcom commented Sep 5, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

deadprogram commented Sep 17, 2026

Uh oh!

neomantra commented Sep 18, 2026

Uh oh!

deadprogram commented Sep 19, 2026

Uh oh!

neomantra commented Sep 19, 2026

Uh oh!

deadprogram left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

neomantra commented Aug 28, 2026

Summary

Problem

Fix

Verification

Context

Uh oh!

0pcom commented Sep 5, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

deadprogram commented Sep 17, 2026

Uh oh!

neomantra commented Sep 18, 2026

Uh oh!

deadprogram commented Sep 19, 2026

Uh oh!

neomantra commented Sep 19, 2026

Uh oh!

deadprogram left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants